NIP publishing on 2 ADH without multicast

I'm working on a NIP which needs to publishes on my TREP infrastructure. Here's my need:

  • One NIP
  • Two ADH
  • I can't use multicast on the server which hosts the NIP
  • I need a fault tolerant solution on the TREP side

Here's what I'm doing currently:

image

And here’s my test scenario:

  1. I start the ADH pair:
    hot standby : ADH1 active / ADH2 standby
    cache resiliency : True
    cache percistency : True
  2. I start the NIP
  3. When the NIP starts, it connects to the first server of its list: ADH1
  4. My NIP publishes a couple of updates on InstrumentA
  5. I shutdown the NIP
  6. I kill ADH1
  7. If I dump the cache of ADH2, there’s no trace of InstrumentA <= this is a problem

Another scenario:

  1. I start the ADH pair (same configuration)
  2. I start the NIP
  3. When the NIP starts, it connects to ADH1
  4. My NIP publishes a couple of updates on InstrumentA
  5. I kill the ADH1. (ADH2 is now active)
  6. The NIP connects to ADH2
  7. I restart the ADH1. (ADH2 is still active, so ADH1 is standby)
  8. I kill the NIP
  9. I start the NIP

The NIP connects to the first server of its list: ADH1 (which is standby) <= this is another problem…

Am I doing something wrong?
Is there something I should do on my NIP in order to post simultaneously (via RSSL, because I can't use multicat) on both ADH?

Best Answer

  • Hi @nicolas.roux

    I am not sure which TREP API you are using but I assume it is RFA.

    If you want RFA to connect to both ADH, you have to use connectionList.

    \Sessions\SessionOMMNIProv\connectionList = "Connection_RSSL_NIPROV,Connection_RSSL_NIPROV2"


    \Connections\Connection_RSSL_NIPROV\connectionType = "RSSL_NIPROV"
    \Connections\Connection_RSSL_NIPROV\rsslPort = "14003"
    \Connections\Connection_RSSL_NIPROV\hostName = "192.168.27.30"

    \Connections\Connection_RSSL_NIPROV2\connectionType = "RSSL_NIPROV"
    \Connections\Connection_RSSL_NIPROV2\rsslPort = "14003"
    \Connections\Connection_RSSL_NIPROV2\hostName = "192.168.27.60"

    With this configuration, RFA should connect and publish to both ADHs.

Answers

  • I'm working on a NIP which needs to publishes on my TREP infrastructure. Here's my need:

    • One NIP
    • Two ADH
    • I can't use multicast on the server which hosts the NIP
    • I need a fault tolerant solution on the TREP side

    Here's what I'm doing currently:

    image

    And here’s my test scenario:

    1. I start the ADH pair:
      hot standby : ADH1 active / ADH2 standby
      cache resiliency : True
      cache percistency : True
    2. I start the NIP
    3. When the NIP starts, it connects to the first server of its list: ADH1
    4. My NIP publishes a couple of updates on InstrumentA
    5. I shutdown the NIP
    6. I kill ADH1
    7. If I dump the cache of ADH2, there’s no trace of InstrumentA <= this is a problem

    Another scenario:

    1. I start the ADH pair (same configuration)
    2. I start the NIP
    3. When the NIP starts, it connects to ADH1
    4. My NIP publishes a couple of updates on InstrumentA
    5. I kill the ADH1. (ADH2 is now active)
    6. The NIP connects to ADH2
    7. I restart the ADH1. (ADH2 is still active, so ADH1 is standby)
    8. I kill the NIP
    9. I start the NIP

    The NIP connects to the first server of its list: ADH1 (which is standby) <= this is another problem…

    Am I doing something wrong?

    Is there something I should do on my NIP in order to post simultaneously (via RSSL, because I can't use multicat) on both ADH?
  • (sorry, I posted my question in the "answer"... I'm still new with the forum and I don't see how to edit my question)

  • Thanks a lot Warat, it's working perfectly fine!

    I just had to modify the Reuters example (ommprovnimdi /

    LoginClient.java) in order to always call processLogin(true) as it's explained in the code comments:

    // If there is more than one Connection, then this could would 
    // need to be changed to always call processLogin(true) when the
    // re is a refresh. In general, if applications wish to use two
    // Connections, it is recommended that they use two Sessions.
    // (...)

    // if (!_loggedIn)
    //{
    _loggedIn = true;
    _mainApp.processLogin(true);
    //}
    }